Information Flow Safety in Multiparty Sessions 



Sara Capecchi 

Dipartimento di Informatica 
Universita di Torino, corso Svizzera 185, 10149 Torino, Italy* 

capecchiOdi .unito . it 

Ilaria Castellani 

INRIA 

2004 route des Lucioles, 06902 Sophia Antipolis, France 
ilaria . castellani@inria . f r 

Mariangiola Dezani-Ciancaglini 

Dipartimento di Informatica 
Universita di Torino, corso Svizzera 185, 10149 Torino, Italy 

dezaniOdi . unito . it 



Abstract We consider a calculus for multiparty sessions enriched with security levels for messages. We 
propose a monitored semantics for this calculus, which blocks the execution of processes as soon as they 
attempt to leak information. We illustrate the use of our monitored semantics with various examples, and 
show that the induced safety property implies a noninterference property studied previously. 
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1 Introduction 

With the advent of web technologies, we are faced today with a powerful computing environment which 
is inherently parallel, distributed and heavily relies on communication. Since computations take place 
concurrently on several heterogeneous devices, controlled by parties which possibly do not trust each 
other, security properties such as confidentiality and integrity of data become of crucial importance. 

A session is an abstraction for various forms of "structured communication" that may occur in a 
parallel and distributed computing environment. Examples of sessions are a client-service negotiation, a 
financial transaction, or an interaction among different services within a web application. Session types, 
which specify the expected behaviour of participants in sessions, were originally introduced in |[l31 . on 
a variant of the 7r-calculus ifTTI including a construct for session creation and two rc-ary operators of 
labelled internal and external choice, called selection and branching. The basic properties ensured by 
session types are the absence of communication errors (communication safety) and the conformance to 
the session protocol (session fidelity). Since then, more powerful session calculi have been investigated, 
allowing delegation of tasks among participants and multiparty interaction within a single session, and 
equipped with increasingly sophisticated session types, ensuring additional properties like progress. 

In previous work J5), we addressed the question of incorporating security requirements into session 
types. To this end, we considered a calculus for multiparty sessions with delegation, enriched with se- 
curity levels for both session participants and data. We proposed a session type system for this calculus, 
adding access control and secure information flow requirements in the typing rules in order to guarantee 
the preservation of data confidentiality during session execution. 

*Work partially funded by the ANR-08-EMER-010 grant PARTOUT, and by the MIUR Projects DISCO and IPODS. 
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In this paper, we move one step further by equipping the above calculus with a monitored semantics, 
which blocks the execution of processes as soon as they attempt to leak information, raising an error. 
Typically, this happens when a process tries to participate in a public communication after receiving or 
testing a secret value. This monitored semantics induces a natural notion of safety on processes: a pro- 
cess is safe if all its monitored computations are successful (in a dynamically evolving environment and 
in the presence of a passive attacker, which may only change secret information at each step). 

Expectedly, this monitored semantics is closely related to the security type system presented in 0. 
Indeed, some of the constraints imposed by the monitored operational rules are simply lifted from the 
typing rules. However, there are two respects in which the constraints of the monitoring semantics are 
simpler. First, they refer to individual computations. In other words, they are local whereas type con- 
straints are both local and global. Second, one of these constraints (the lower bound for the level of 
communications in a given session) may be dynamically computed during execution, and hence services 
do not need to be statically annotated with levels, as was required by the type system of 0. This means 
that the language itself may be simplified when the concern is on safety rather than typability. 

Other advantages of safety over typability are not specific to session calculi. Like security, safety 
is a semantic notion. Hence it is more permissive than typability in that it ignores unreachable parts of 
processes: for instance, in our setting, a high conditional with a low branch will be ruled out by the type 
system but will be considered safe if the low branch is never taken. Safety also offers more, flexibility 
than types in the context of web programming, where security policies may change dynamically. 

Compared to security, safety has again the advantage of locality versus globality. In session calculi, 
it also improves on security in another respect. Indeed, in these calculi processes communicate asyn- 
chronously and messages transit in queues before being consumed by their receivers. Then, while the 
monitored semantics blocks the very act of putting a public message in the queue after a secret message 
has been received, a violation of the security property can only be detected after the public message has 
been put in the queue, that is, after the confidentiality breach has occurred, and possibly already caused 
damage. This means that safety allows early leak detection, whereas security only allows late detection. 

Finally, safety seems more appealing than security when the dangerous behaviour comes from an 
accidental rather than an intentional transgression of the security policy. Indeed, in this case a monitored 
semantics could offer useful feedback to the programmer, in the form of informative error messages. 
Although this possibility is not explored in the present paper, it is the object of ongoing work. 

The main contribution of this work is a monitored semantics for a multiparty session calculus, and 
the proof that the induced information flow safety property strictly implies the information flow security 
property of [5 ]. While the issue of safety has recently received much attention in the security community 
(see Section [7]), it has not, to our knowledge, been addressed in the context of session calculi so far. 

The rest of the paper is organised as follows. In Section[2]we motivate our approach with an example. 
Section[3]introduces the syntax and semantics of our calculus. In Section|4]we recall the definition of se- 
curity from [5] and illustrate it with examples. Section |5]presents our monitored semantics and Section[6] 
introduces our notion of safety and establishes its relation to security. Finally, Section [7] concludes with 
a discussion on related and future work. 

2 Motivating example 

Let us illustrate our approach with an introductory example, inspired by [2]. Suppose we want to model 
the interaction between an online health service S and a user U. Each time the user wishes to consult the 
service, she opens a connection with the server and sends him her username (here by convention we shall 
use "she" for the user and "he" for the server), assuming she has previously registered with the service. 
She may then choose between two kinds of service: 
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I = d[2] 

U = a[l](ai).ai!(2,un- L ). if simple^ then a { ® L (2, svl).ai!(2, que- 1 ). a 1 l(l,ans ± ). 

else a\ ® L (2,sv2).ai !(2, pwd T ).ai? (2, /onn T ). 
if gooduse(form T ) then Gti !(2,que T ).ai?(2,an.y T ).0 
else ai!(2, que- 1 ). G!i?(2, arcs- 1 ). 

S = a[2](a 2 ). a 2 ?(l,«?i- L ). 

a 2 & x (l, {svl : a2?(l,?we- L ).a2!(l,ans- L ).0, 

sv2: a2?(l, j pwJ T ).a 2 !(l,form T ).a2?(l,^ T ).a 2 !(l,ans T ).0} 

Figure 1 : The online medical service example. 

1. simple consultation: the user asks questions from the medical staff. Questions and answers are public, 
for instance they can be published in a forum visible to every user. The staff has no privacy constraint. 

2. medical consultation: the user sends questions together with private data (e.g., results of medical 
exams) to the medical staff, in order to receive a diagnosis or advice about medicines or further exams. 
To access these features she must enter a password, and wait for a secure form on which to send her 
data. Here questions and answers are secret (modelling the fact that the they are sent in a secure mode 
and that the staff is compelled to maintain privacy). 

More precisely, this interaction may be described by the following protocol, in which we add the possi- 
bility that the user accidentally reveals her private information: 

1. U opens a connection with S and sends her username to S; 

2. U chooses between Service 1 and Service 2; 

3. a Service 1: U sends a question to S and waits for an answer; 

3.b Service 2: U sends her password to S and waits for a secure form. She then sends her question and 
data on the form and waits for an answer from S. A reliable user will use the form correctly and send 
data in a secure mode. Instead, an unreliable user will forget to use the form, or use it wrongly, thus 
leaking some of her private data. This may result in private information being sent to a public forum 
or to medical staff which is not compelled to maintain privacy. 

In our calculus, this scenario may be described as the parallel composition of the processes in Figure[T] 
A session is an activation of a service, involving a number of participants with predefined roles. 
Here processes U and S communicate by opening a session on service a. The initiator a{2] specifies that 
the number of participants is 2. Participants are denoted by integers: here U=l, S=2. In process U, the 
prefix a[l](cti) means that U wants to act as participant 1 in service a, using channel (X\ to communicate. 
Dually, in S, a[2]((X2) means that S will act as participant 2 in service a, communicating via channel o^- 
Security levels appear as superscripts on both data and some operators (here _L means "public" and 
T means "secret"): the user name un and the message contents in Service 1 can be public; the password 
pwd and the information exchanged in Service 2 should be secret. Levels on the operators are needed to 
track indirect flows, as will be explained in Section [6] They may be ignored for the time being. 

When the session is established, via a synchronisation between the initiator and the prefixes a[i] (a,), 
U sends to S her username un- 1 . Then, according to whether she wishes a simple consultation or not, 
she chooses between the two services svl- 1 and sy!^. This choice is expressed by the internal choice 
construct ©: if simple^- then ai ©- 1 (2, svl) . . . else ot\ ©- 1 (2,sv2) . . . describes a process sending on 
(X\ to participant 2 either label svl or sv2, depending on the value of simple^-. If U chooses svl, then 
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she sends to S a question (construct (X\ !(2,que J -}), receives the answer (construct ai?(l, ans 1 )). If U 
chooses sv2, then she sends her password to S and then waits to get back a secure form. At this point, 
according to her reliability (if gooduse(form T )) she either sends her question and data in the secure 
form, or wrongly sends them in clear. The difference between the secure and insecure exchanges is 
modelled by the different security levels tagging values and variables in the prefixes ai!(2,que T//J -} and 
ai?(2,a?i5 T /- L ). 

Dually, process S receives the username from U and then waits for her choice of either label svl or 
label sv2. This is described by the external choice operator &: & (1, {svl : . . . ,sv2 : . . .) expresses the 
reception of the label svl or of the label sv2 from participant 1. In the first case, S will then receive a 
question and send the answer. This whole interaction is public. In the second case, S receives a password 
and sends a form, and then receives a question and sends the answer. In this case the interaction is secret. 

Note that the execution of process I | S | U may be insecure if U is unreliable. Indeed, in U's code, the 
test on gooduse (form 1 ) uses the secret value form 1 . Now, for security to be granted in the subsequent 
execution, all communications depending on form 1 should be secret. However, this will not be the case 
if the second branch of the conditional is taken, since in this case U sends a public question. On the other 
hand, the execution is secure when the first service is used, or when the second service is used properly. 

This process is rejected by the type system of (H, which must statically ensure the correction of 
all possible executions. Similarly, the security property of [5] fails to hold for this process, since two 
different public behaviours may be exhibited after testing the secret value gooduse (form 1 ): in one case 
the empty behaviour, in the other case the emission of que- 1 . Moreover, the bisimulation used to check 
security will fail only once que 1 has been put in the queue, and thus possibly exploited by an attacker. 
By contrast, the monitored semantics will block the very act of putting que- 1 in the queue. 

For the sake of conciseness, we deliberately simplified the scenario in the above example, by using 
finite services and a binary session between a server and a user. Note that several such sessions could run 
in parallel, each corresponding to a different impersonation of the user. A more realistic example would 
involve persistent services and allow several users to interact within the same session, and the server 
to delegate the question handling to the medical staff. This would bring into the scene other important 
features of our calculus, namely multiparty interaction and the mechanism of delegation. Our simple 
example is mainly meant to highlight the novel issue of monitored execution. 

3 Syntax and Standard Semantics 

Our calculus is essentially the same as that studied in [5]. For the sake of simplicity, we do not consider 
here access control and declassification, although their addition would not pose any problem. 

Let (y, <) be a finite lattice of security levels, ranged over by £,£'. We denote by U and n the join 
and meet operations on the lattice, and by _L and T its minimal and maximal elements. We assume the 
following sets: values (booleans, integers), ranged over by v, V . . ., value variables, ranged over by x,y . . ., 
service names, ranged over by a,b,..., each of which has an arity n>2 (its number of participants), 
service name variables, ranged over by identifiers, i.e., service names and value variables, 

ranged over by u, w, . . ., channel variables, ranged over by a, J3 , . . ., and labels, ranged over by X , X', . . . 
(acting like labels in labelled records). Sessions, the central abstraction of our calculus, are denoted 

with s,s' A session represents a particular instance or activation of a service. Hence sessions only 

appear at runtime. We use p, q,. . . to denote the participants of a session. In an n-axy session (a session 
corresponding to an n-ary service) p, q are assumed to range over the natural numbers 1 , . . . , n. We denote 
by IT a non empty set of participants. Each session s has an associated set of channels with role s[p], 
one for each participant. Channel s[p] is the private channel through which participant p communicates 
with the other participants in the session s. A new session s on an n-aiy service a is opened when the 
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r 


:= a | s 


Service/Session Name 


c 


:= a | s[p] 


Channel 


u 


■■= C II « 


Identifier 


V 


:= true false 


Value 




■ — y^' 1 \}^ 1 nnt /- 1 

. — A, \\ V IIUL t 






e and e' \ . .. 


Expression 


D 


:= X(x,a)=P 


Declaration 


n 


■= Id! i nulpl 


Set of participants 


& 


:= / 1 s\pf 1 A'' 


Message content 


m 


:= ( P ,n,t?) 


Message in transit 


h 


:= m • /i | e 


Queue 


H 


:= U !>:/;} | 


Q-set 



u[n] 


n-SLvy session initiator 


u\r>](a).P 


p-th session participant 


c\{U,e).P 


Value send 


c?(p,x f ).P 


Value receive 


cK(n,w)..p 


Service name send 




Service name receive 


L ■ WH: L // 1 


Channel send 


r^lYr> ra^ P 

C - UP;"!/-* 


("'hfinnpl rpppivp 

V lltlllll^l 1 ^ V_ V, 1 V w 


/■ ff/ /TT /) \ P 


OClCLUUIl 




Branching 


if e then P else 2 


Conditional 


P| Q 


Parallel 





Inaction 


(va)P 


Name hiding 


def £» in P 


Recursion 


X{e,c) 


Process call 



Table 1: Syntax of processes, expressions and queues. 



initiator a[n] of the service synchronises with n processes of the forma[l](ai).Pi, . . . ,a[n]{a n ).P n , whose 
channels Op then get replaced by s[p] in the body of P p . While binary sessions may often be viewed as 
an interaction between a user and a server, multiparty sessions do not exhibit the same asymmetry. This 
is why we use of an initiator to start the session once all the required "peer" participants are present. 
We use c to range over channel variables and channels with roles. Finally, we assume a set of process 
variables X, Y, . . . , in order to define recursive behaviours. 

As in O, in order to model TCP- like asynchronous communications (with non-blocking send but 
message order preservation between a given pair of participants), we use queues of messages, denoted by 
h; an element of h may be one of the following: a value message (p,n, v e ), indicating that the value v is 
sent by participant p to all participants in 11; a service name message (p,n,</), with a similar meaning; 
a channel message (p, q, sfp'f'), indicating that p delegates to q the role of p' with level £ in session s; and 
a label message (p,IT, X ), indicating that p selects the process with label A among those offered by the 
set of participants n. The empty queue is denoted by e, and the concatenation of a message m to a queue 
h by h • m. Conversely, m • h means that m is the head of the queue. Since there may be interleaved, nested 
and parallel sessions, we distinguish their queues with names. We denote by s : h the named queue h 
associated with session s. We use H,K to range over sets of named queues with different session names, 
also called Q-sets. 

Table [I] summarises the syntax of expressions, ranged over by e,e' , . . . , and of processes, ranged over 
by P, Q . . . , as well as the runtime syntax of the calculus (sessions, channels with role, messages, queues). 

Let us briefly comment on the primitives of the language. We already described session initiation. 
Communications within a session are performed on a channel using the next four pairs of primitives: the 
send and receive of a value; the send and receive of a service name; the send and receive of a channel 
(where one participant transmits to another the capability of participating in another session with a given 
role) and the selection and branching operators (where one participant chooses one of the branches 
offered by another participant). Apart from the value send and receive constructs, all the send/receive 
and choice primitives are decorated with security levels, whose use will be justified later. When there is 
no risk of confusion we will omit the set delimiters {, }, particularly around singletons. 

The operational semantics consists of a reduction relation on configurations < P , H >, which are 
pairs of a process P and a Q-set H. Indeed, queues need to be isolated from processes in our calculus 
(unlike in other session calculi, where queues are handled by running them in parallel with processes), 
since they will be the observable part of processes in our security and safety notions. 
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a[l](ai).Pi | ... | a[n](a n ).P n \ a[n] — > (vs) < Pi{s[l]/ai} | ... | P n {s[n]/a n } , s : £ > 

[Link] 

< s[p}\(U,e).P , s:h > — >< P , s : h ■ (p,n,v*) > where e\.v e 

[SendV] 

< s[q]^(p,x e ).P , s: (p,q,v e )-h> — ><P{v/x} ,s:h> 

[RecV] 

<s[p}\ e (n,a).P , s:h> — ><P , s:h-(p,U,a e ) > 

[SendS] 

< s[q]f(p, Q.P,s: (p, q y ) • h > ^< P{a/Q ,s:h> 

[RecS] 

< s\p]\ e ((q, S y])).P ,s:h >^< P , s : h- (p,q/[pf ) > 

[SendC] 

< s[q\f((p,a)).P , s : (p,q,^[pf ) -h >^< P{s'\p']/a} , s : h > 

[RecC] 

<s[p] £ (n,A).P, j:/i> — ^</ 5 , 5:/j-(p,n,A £ ) > 

[Label] 

< s[q}& { (p,{li : Pi} ieI ) , s : (p,q,A/ Q ) -h > — X P k) , s : h > where (i G /) 

[Branch] 

if e then P else Q — > P where e J, true £ if e then P else 2 — > Q where e ], false 

[If-T, If-F] 

defX(jc,a) =PinX(e,j[p]) — > def X(x,a) = P m P{v { /x}{s[p]/a} wheree|v £ 

[Def] 

<P , H > — ► (vj) < P' , H' > => 

< def D in (P | , // > — ► (v5) < def D in (P | Q) , H ' > 

[Defin] 

C — ► (V5)C => (vr)(C|| C") — > (vr)(vl)(C || C") 

[Scop] 

Table 2: Standard reduction rules. 

A configuration is a pair C = < P , H > of a process P and a Q-set //, possibly restricted with respect 
to service and session names, or a parallel composition (C\\ C') of two configurations whose Q-sets have 
disjoint session names. In a configuration (vs) < P , H >, all occurrences of s\p] in P and H and of 5 in 
H are bound. By abuse of notation we often write P instead of < P , >. 

As usual, the operational semantics is defined modulo a structural equivalence =. The structural rules 
for processes are standard ifTTIl . Among the rules for queues, we have one for commuting independent 
messages and another one for splitting a message for multiple recipients. The structural equivalence of 
configurations allows the parallel composition || to be eliminated via the rule: 

(Vf) < P , H > || (vf) < Q , K > = (Vff) < P | Q , HUK > 

where by hypothesis the session names in the Q-sets H, K are disjoint, by Barendregt convention f and 
r 1 have empty intersection and there is no capture of free names, and (vf)C stands for (yr\) ■ ■ ■ (vr^)C, 
if f = n • • • 7>. Note that, modulo =, each configuration has the form (vf) < P , H >. 

The transitions for configurations have the form C — > C'. They are derived using the reduction rules 
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in Table [2j where we write P as short for < P , >. 

Rule [Link] describes the initiation of a new session among n processes, corresponding to an activa- 
tion of the service a of arity n. After the connection, the participants share a private session name s and 
the corresponding queue, initialised to s : e. In each participant P p , the channel variable Op is replaced 
by the channel with role s[p]. This is the only synchronous interaction of the calculus. All the other 
communications, which take place within an established session, are performed asynchronously in two 
steps, via push and pop operations on the queue associated with the session. 

The output rules [SendV], [SendS], [SendC] and [Label] push values, service names, channels and 
labels, respectively, into the queue s : h. In rule [SendV], e J, v e denotes the evaluation of the expression 
e to the value v , where I is the join of the security levels of the variables and values occurring in e. 

The input rules [RecV], [RecS], [RecC] and [Branch] perform the complementary operations. Rules 
[If-T], [If-F], [Def] and [Defin] are standard. The contextual rule [Scop] is also standard. In this rule, 
Barendregt convention ensures that the names in s are disjoint from those in r and do not appear in C" . 
As usual, we use — >* for the reflexive and transitive closure of — >. 

We assume that communication safety and session fidelity are assured by a standard session type 
system ||9] 

4 Security 

As in 0, we assume that the observer can see the messages in session queues. As usual for security, 
observation is relative to a given downward-closed set of levels Jzf C 5?, the intuition being that an ob- 
server who can see messages of level £ can also see all messages of level £' lower than I. In the following, 
we shall always use Jzf to denote a downward-closed subset of levels. For any such Jzf , an Jzf-observer 
will only be able to see messages whose levels belong to Jzf , what we may call Jzf '-messages. Hence two 
queues that agree on Jzf-messages will be indistinguishable for an Jzf-observer. Let now ^-messages 
be the complementary messages, those the Jzf-observer cannot see. Then, an Jzf-observer may also be 
viewed as an attacker who tries to reconstruct the dependency between Jzf-messages and Jzf-messages 
(and hence, ultimately, to discover the Jzf-messages), by injecting himself different Jzf-messages at each 
step and observing their effect on Jzf-messages. 

To formalise this intuition, a notion of Jzf-equality =y on Q-sets is introduced, representing indis- 
tinguishability of Q-sets by an Jzf -observer. Based on =_g>, a notion of Jzf-bisimulation formalises 
indistinguishability of processes by an Jzf -observer. Formally, a queue s : h is Jzf -observable if it contains 
some message with level in Jzf. Then two Q-sets are Jzf '-equal if their Jzf-observable queues have the 
same names and contain the same messages with level in Jzf. This equality is based on an Jzf-projection 
operation on Q-sets, which discards all messages whose level is not in Jzf. 

Let the function lev be given by: lev(v e ) = lev(a e ) = lev(s{p] e ) = lev{X ) = I. 

Definition 4.1 (Jzf -Projection) The projection operation JJ- Jzf is defined inductively on messages, queues 
and Q-sets as follows: 




0^ Jzf = 



{H\J{s:h})tySf 




Definition 4.2 (Jz^-Equality of Q-sets) 

Two Q-sets H and K are Jzf -equal, written H=%K,ifH^J£ = Kl^£. 
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The idea is to test processes by running them in conjunction with Jzf-equal queues. However, we 
cannot allow arbitrary combinations of processes with queues, since this would lead us to reject intu- 
itively secure processes as simple as s[2]?(l,^- L ).0 and s[l] !(2,true J -}.0. As argued in 0, we may get 
around this problem by imposing two simple conditions, one on Q-sets (monotonicity) and the other on 
configurations (saturation). These conditions are justified by the fact that they are always satisfied in 
initial computations generated by typable processes (in the sense of Il5l0. 

The first condition requires that in a Q-set, the security levels of messages with the same sender and 
common receivers should never decrease along a sequence. 

Definition 4.3 (Monotonicity) A queue is monotone if lev ) < lev(ih) whenever the message (p , n i , #i ) 
precedes the message (p, 112, $2) in the queue and II 1 fl II2 7^ 0. 

The second condition requires that in a configuration, the Q-set should always contain enough queues 
to enable all outputs of the process to reduce. 

Definition 4.4 (Saturation) A configuration (P, H) is saturated each session name s occurring in P 
has a corresponding queue s : h in H. 

We are now ready for defining our Jzf -bisimulation, expressing indistinguishability by an ^-observer. 
Unlike early definitions of Jzf -bisimulation, which only allowed the "high state" to be changed at the start 
of computation, our definition allows it to be changed at each step, to account for dynamic contexts Q. 
Definition 4.5 (Jzf -Bisimulation) 

A symmetric relation C (£Pr x &r) is a Jzf -bisimulation if Pi &P 2 implies, for any pair of monotone 
Q-sets Hi and H 2 such that Hi =^ H 2 and each < Pi , Hi > is saturated: 

If < Pi , Hi > — > (vf) < P[ , H[ >, then there exist P 2 ,H 2 such that 
<P 2 ,H 2 > — >* = (vf) <P' 2 ,H' 2 >, where H[=^H' 2 and P[@P' 2 . 

Processes Pi,P 2 are Jzf-bisimilar, Pi ~ % P 2 , if Pi MP 2 for some J£ -bisimulation 

Note that r may either be the empty string or a single name, since it appears after a one-step transition. If it 
is a name, it may either be a service name a (communication of a private service) or a fresh session name 
s (opening of a new session). In the latter case, s cannot occur in P 2 and H 2 by Barendregt convention. 

Intuitively, a transition that adds or removes an Jzf-message must be simulated in one or more steps, 
producing the same effect on the Q-set, whereas a transition that does not affect Jzf -messages may be 
simulated by inaction. In such case, the structural equivalence = may be needed in case the first process 
has created a restriction. The notions of Jzf-security and security are now defined in the standard way: 
Definition 4.6 (Security) 

1. A process is Jzf -secure if it is J£-hisimilar with itself. 

2. A process is secure if it is Jzf '-secure for every Jzf. 

The need for considering all downward-closed sets Jzf is justified by the following example. 
Example 4.7 Let y = {±,1, T} where _L < £ < T and 
P = a[2] I a[l](ai).Pi I a[2](a 2 ).P 2 

Pi = ai?(2,x T ).if x T then ai!(2,false £ ).0else ai!(2,trueO.O 
P 2 = a 2 !(l,true T ).0 

The process P is {Insecure and 5^-secure, hut it is not {-L,^} -secure, since there is a flow from level 
T to level t in Pi, which is detectable by a {_L, £}-observer but not by a {±}-observer. We let the reader 
verify this fact formally, possibly after looking at the next example. 

We show next that an input of level £ should not be followed by an action of level £' ^ £: 
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Example 4.8 (Insecurity of high input followed by low action) 
Consider the process P and the Q-sets Hi and H 2 , where Hi ={±} H2: 

P = s[2]l(l,x T ).s[2]\(l,tme x ).0, Hi = {s : (l,2,true T )} H 2 = {s : s} 

Here we have < P , Hi > — ►< s[2] !(l,true- L ).0 , {s : e} >=< Pi , H[ >, while < P , H 2 >-/-*. Since 
H[ = {s : e} = H2, we can proceed with P\ = s[2]\(l, true- 1 ) .0 and P2 = P. Take now Ki = K 2 = {s : £}. 
Then < Pi , K x > — ^<0, {s : (2, 1, true- 1 )} >, while <P 2 , K 2 >-/->. Since K[ = {s : (2, Ttrue- 1 )} 
{s : e} = K 2 , P is not {lS\-secure. 

With a similar argument we may show that Q = s[2]!(l,x T ).s[2]?(l,y- L ).0 is not {Insecure. 

The need for security levels on value variables are justified by the following example. 
Example 4.9 (Need for levels on value variables) 

Suppose we had no levels on value variables. Consider the process, which should be secure: 

P = j[l]?(2,x).j[l]7(2,y).0 I 5[2]!(l,true ± ).5[2]!(l,true ± ).0 

Let Hi = {s : (2, l,true T )} =<g {s : e} = H 2 . Then the transition: 

<P,Hi >— Kj[l]?(2,;y).0 | 5[2]!(l,true ± ).5[2]!(l,true ± ).0 , {s : e} >=< Pi , H[ > 

could not be matched by < P , H 2 >. In fact, the first component of P cannot move in H 2 , and each 
computation of the second component yields an J£ -observable H' 2 such that H[ 7^{j_} H' 2 . Moreover, P 
cannot stay idle in H 2 , since P is not Jzf -bisimilar to Pi (as it is easy to see by a similar reasoning). 
By adding the level _L to the variables x and y, we force the second component to move first in both 
< P , Hi > and <P , H 2 >. 

Interestingly, an insecure component may be "sanitised" by its context, so that the insecurity is 
not detectable in the overall process. Clearly, in case of a deadlocking context, the insecurity is masked 
simply because the dangerous part is not executed. However, the curing context could also be a partner of 
the insecure component, as shown by the next example. This example is significant because it constitutes 
a non trivial case of a process that is secure but not safe, as will be further discussed in Section [6j 

Example 4.10 (Insecurity sanitised by parallel context) 



Let R be obtained by composing the process P of Example 4.8 in parallel with a dual process P, and 
consider again the Q-sets Hi and H 2 , where Hi ={j_} H 2 : 

R=P\P = 5[2]?(l,x T ).^[2]!(l,true ± ).0 | s[l}l(2,true T ).s[l]?(2,y^).0 
Hi={s:(l,2,true T )} H 2 = {s:e} 

Then the move <P \ P , H\ > — X 5 , [2]!(l,true J -).0 | P , {s : e} > can be simulated by the sequence of 
two moves 

<P\P,H 2 > — P I s[l}?(2,y ± ).0 , {s : (l,2,true T )} > 
— > < s[2]!(l,true x }.0 | s[l}?{2,y ± ).0 , {s : e} >, 

where H[=H' 2 = {s: e}. 

Let us now compare the processes Ri = s[2] !(l,true J -).0 | P and R 2 = s[2] [(ljtrue^.O | s[l]?(2, y^)^. 
Let Ki,K 2 be monotone Q-sets containing a queue s : h and such that Ki ={j_} K 2 . Now, if < R x , Ki > 
moves first, either it does the high output of P, in which case < R 2 , K 2 > replies by staying idle, since 
the resulting processes will be equal and the resulting queues K[,K 2 will be such that K[ ={j_} K 2 , or 
it executes its first component, in which case < R 2 , K 2 > does exactly the same, clearly preserving the 
{.L}-equality of Q-sets, and it remains to prove that P = 5[l]!(2,true T ).i[l]?(2,y- L ).0 is ^-bisimilar to 
i[l]?(2,j- L ).0. But this is easy to see since if the first process moves, the second may stay idle, while if 
the second moves, the first may simulate it in two steps. 
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Conversely, if<R 2 ,K 2 > moves first, either it executes its second component ( if the queue allows it), 
in which case < R\ , K\ > simulates it in two steps, or it executes its first component, in which case we 
are reduced once again to prove that P = s[l] !(2,true T )..s'[l]?(2,;y ).0 is ^-bisimilar to ^[l]?(2,y- L ).0. 

5 Monitored Semantics 

In this section we introduce the monitored semantics for our calculus. This semantics is defined on 
monitored processes M,M', whose syntax is the following, assuming pt G 

M ::= P^\M\M\ {va)M || def D in M 

In a monitored process P^, the level pt that tags P is called the monitoring level for P. It controls the 
execution of P by blocking any communication of level IX. Intuitively, P^ represents a partially 
executed process, and pt is the join of the levels of received objects (values, labels or channels) and of 
tested conditions up to this point in execution. 

The monitored semantics is defined on monitored configurations C =< M , H >. By abuse of nota- 
tion, we use the same symbol C for standard and monitored configurations. 

The semantic rules define simultaneously a reduction relation C — °— > C and an error predicate C f 
on monitored configurations. As usual, the semantic rules are applied modulo a structural equivalence 
=. The new specific structural rules are: 

(Pi | P 2 )^ = P} 1 I P] 11 Cf A C = C => Cf 

The reduction rules of the monitored semantics are given in Table [3] Intuitively, the monitoring level 

is initially _L and gets increased each time a test of higher or incomparable level or an input of higher 

level is crossed. Moreover, if < P^ , H > attempts to perform a communication action of level t^jt\l, 

then < P^ , H > f- We say in this case that the reduction produces error. 

The reason why the monitoring level should take into account the level of inputs is that, as argued in 

Section|4j the process *[1]?(2,a; t ).5[1] !(2,true ± ).0 is not secure. Hence it should not be safe either. 
One may wonder whether monitored processes of the form Pj^ 1 | P^ 11 , where pL\ / /I2, are really 

needed. The following example shows that, in the presence of concurrency, a single monitoring level (as 

used for instance in j4[) would not be enough. 

Example 5.1 (Need for multiple monitoring levels) 

Suppose we could only use a single monitoring level for the parallel process P below, which should 

intuitively be safe. Then a computation of P~\ ^ would be successful or not depending on the order of 

execution of its parallel components: 

Pi =«i!(2,true- L ).0 P 2 = a 2 ?(l,^- L ).0 
P 3 = a 3 !(4,true T ).0 P 4 = a 4 ?(3,j T ).0 
P = a[4] I a[l](ai).Pi | a[2](a 2 ).P 2 | a[3](a 3 ).P 3 | a[4](a 4 ).P 4 

Here, if Pi and P 2 communicate first, we would have the successful computation: 

pl-L_o-»*( Vl r) < (P 3 {s[3]/a 3 } I P 4 {s[4]/a 4 })^ , s : e >^ (vs) < 0^ T , s : e > 

Instead, ifPj, and P 4 communicate first, then we would run into error: 

pl-L^*( Vj ) < (fl{j[l]/ai} I P 2 {s[2]/a 2 })l T , s : £ > f 

Intuitively, the monitoring level resulting from the communication of P 3 and P 4 should not constrain 
the communication of Pi and P 2 , since there is no causal dependency between them. Allowing different 
monitoring levels for different parallel components, when P 3 and P 4 communicate first we get: 

pU^*(vs) < 0l T I (Pi{s[l]/ai} I P 2 {j[2]/a 2 }) lx , s : e > -^*(vs) < 0^ T | 0^ , s : e > 
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«[l](a 1 ).P 1 1 ' 11 | ... | a [»](a„).pJ' 1 " | a[ n ]Wi 

(vs) < Pi{ s [l]/ai}l" | ... | P^M/aJ^ ,s:e> 
where ju = Lk{i...„+i} Mi [MLink] 

if jU <^ then <s[p]!(n,e).pl' J , s :h>-°-+< P\» , s:ft- (p,n,v £ ) > 
else <5[p]!(n,e).pl' J , s: A > t 
where e \. / [MSendV] 

if ju <£ then < i[q]?(p,/).P^ , s : (p,q, /) ■ h >^^< P{v/x}^ ,s:h> 
else < s[q]?(p,/).P^ , s : (p,q,/) - A > t 

[MRecV] 

if jU < £ then < s[p]!^(n,a).pl' 1 , s : /t >-o->< P^ , s : A • (p,II,</) > 
else <s\p]\ e (n,a).P~\» , s:/t>t 

[MSendS] 

if n < i then < s[q]? £ (p,C).P^ , s : foqX) - A >-<>->< P{a/£}^ , s:h> 
else<,[q]?^(p,C).P^^:(p,q,a £ )-A>t 

[MRecS] 

if /i < £ then < s{p}\ e {(q,s'[p'})).P^ ,s:h >^ < Pi" , s : A- (p,q,i'[pf ) > 
else<s[/^((q,s'[p'])).P^,s:/z>f 

[MSendC] 

if jU <^ then <s[q]? £ ((p,a)).P^ , s : (p,q,s'[pf ) ■ h >^< P{s'[p']/a}^ , s : h > 
else <s[q}f((v,a)).P^ , s : (p,q,s'[pf ) • h > f 

[MRecC] 

if ,u <^ then <i[p]® < '(n,A).pl' 1 , s : A >-o-^< plM , s:h-{p,U,X e ) > 
else<s[p] ® e (Yl,X).P^ ,s:h>t 

[MLabel] 

if jU < ^ then<4q]&^(p,{A ! :P} l€ /)l' 1 ,5:(p,q,A^)-A 

else < s[q]&*(p,{A ( - : flW , s : (p,q,^)-A > t 
where z'o € / [MBranch] 
if e then P else glf -o-^plMU* ife|true £ 

if e then P else -o-> Q^ ue if e I fa\se e [MIf-T, MIf-F] 

(def X(x, a) = P in (X(e,s[p])))^ -o-> def X(jc, a) = P in (P{v e /x}{s\p]/a})^ 

where e | v l [MDef] 

<M ,H (vs) <M' ,H' > 

< def D in (M | M") , // (vs) < def D in (M' | M") , H' > 

[MDefin] 

C -o-> (vs~)C and - C"t => (vr)(C || C") -o-». (vf)(vs)(C || C") 

Ct => (vr)(C || C')t [MScopC] 

Table 3: Monitored reduction rules. 
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The following example justifies the use of the join in rule [MLink]. Session initiation is the only 
synchronisation operation of our calculus. Since this synchronisation requires the initiator d[n] as well as 
a complete set of "service callers" a [p](0Ji).P p , 1 < p <n, the monitoring level of each of them contributes 
to the monitoring level of the session. Note that the fact that this monitoring level may be computed 
dynamically as the join of the monitoring levels of the participants exempts us from statically annotating 
services with levels, as it was necessary to do in 1H in order to type the various participants consistently. 

Consider the process: 

s[2]?(l,x T ).if x T then b[2] else | fc[l](j3i).j3i!(2,true x }.0 | Z7[2]( j 8 2 ).j8 2 ?(l,j ± ).0 

Here the monitoring level of the conditional becomes T after the test, and thus, assuming the if 
branch is taken, rule [MLink] will set the monitoring level of the session to T. This will block the 
exchange of the _L-value between the last two components. 

Example 5.2 (Need for security levels on transmitted service names) 

This example shows the need for security levels on service names in rules [MSendS] and [MRecS]. 
s[2]?(l,x T ).ifx T then s[2]\ e (3,a).0 else s[2]\ e {3,b).0 
| ,[3]? £ '(2,?)-?[2] 

| a[l](ai).ai!(2,true- L ).0 | a[2](a 2 ).a 2 ?(l,j- L ).0 
| ft[l]( i 8 1 ). i 8 1 !(2,false ± ).0| fo[2] ( J 8 2 ).j8 2 ?(l,^)-0 

This process is insecure because, depending on the high value received for x T , it will initiate a session on 
service a or on service b, which both perform a low value exchange. Ifi^T, the monitored semantics 
will yield error in the outputs of the first line, otherwise it yields error in the outputs of the last two lines. 

Similar examples show the need for security levels on transmitted channels and labels. 
6 Safety 

We define now the property of safety for monitored processes, from which we derive also a property of 
safety for processes. We then prove that if a process is safe, it is also secure. 

A monitored process may be "relaxed" to an ordinary process by removing all its monitoring levels. 

Definition 6.1 (Demonitoring) IfM is a monitored process, its demonitoring \M\ is defined by: 

\P^\ = P \Mi\M 2 \ = \M\ \ | \M 2 \ 

\{ya)M\ = (va)\M\ |defDinM| = defDin|M| 

Intuitively, a monitored process M is safe if it can mimic at each step the transitions of the process \M\. 
Definition 6.2 (Monitored process safety) 

The safety predicate on monitored processes is coinductively defined by: 
M is safe if for any monotone Q-set H such that < \M\ , H > is saturated: 
If<\M\,H>^ (vf) <P,H'> 

then <M , H >^-> (vf) < M' , H' >, where \M'\ = P and M' is safe. 

Definition 6.3 (Process safety) A process P is safe ifP^ is safe. 

We show now that if a process is safe, then none of its monitored computations starting with mon- 
itor _L gives rise to error. This result rests on the observation that < M , H >^>-^- if and only if 
< \M\ , H > — > and -> < M , H > f, and that if M is safe, then if a standard communication rule is 
applicable to \M\, the corresponding monitored communication rule is applicable to M. 
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Proposition 6.4 (Safety implies absence of run-time errors) 

IfP is safe, then every monitored computation: 

<pU,0>=<M o ,ff o >^(vfi)<Mi,//i >^---(vf k )<M k ,H k > 
is such that -i < M k , > f . 

Note that the converse of Proposition 6.4 does not hold, as shown by the next example. This means 
that we could not use absence of run-time errors as a definition of safety, since that would not be strong 
enough to guarantee our security property, which allows the pair of Jzf-equal Q-sets to be refreshed at 
each step (while maintaining Jzf-equality). 

Example 6.5 

P = a[2] | a[l](ai).Pi | a[2](a 2 ).P 2 
Pi = ai!(2,true T ).ai?(2,.x T ).0 

Pi = 02?(l,z T ).if z T then a 2 !(l,false T ).0 else a 2 !(l,true- L ).0 

Note first that this process is not ^-secure because after Pi has put the value true T in the Q-set, this value 

may be changed to false T while preserving Jzf -equality of Q-sets, thus allowing the else branch ofP 2 to 
be explored by the bisimulation. This process is not safe either, because our definition of safety mimics 
Jtf -bisimulation by refreshing the Q-set at each step. On the other hand, a simple monitored execution 
of < P^ 1 - , >, which uses at each step the Q-set produced at the previous step, would never take the 
else branch and would therefore always succeed. Hence the simple absence of run-time errors would 
not be sufficient to enforce security. 

In order to prove that safety implies security, we need some preliminary results. 
Lemma 6.6 (Monotonicity of monitoring) Monitoring levels may only increase along execution: If 
(P^,H) -o-). (vf)(P'l^' | M,H'), then ju < ii'. 

As usual, Jzf-high processes modify Q-sets in a way which is transparent for ^-observers. 
Definition 6.7 (Jzf -highness of processes) A process P is Jzf-high if for any monotone Q-set H such 
that < P , H > is saturated, it satisfies the property: 

If<P,H> — ► (vf) <P' ,H' >, then H = <£ H' and P' is 5?-high. 

Lemma 6.8 IfP^ is safe and /i ^ Jzf, then P is ££-high. 

We next define the bisimulation relation that will be used in the proof of soundness. Roughly, all 
monitored processes with a high monitoring level are related, while the other processes are related if 
they are congruent. 

Definition 6.9 (Bisimulation for soundness proof: monitored processes) 

Given a downward-closed set of security levels Jzf C Sf, the relation S%^f on monitored processes is 
defined inductively as follows: 

M\ ' M 2 if Mi and M 2 are safe and one of the following holds 

1. Mi = P^ 1 , M 2 = P 2 lM2 and \l\,\l 2 £ ^ ; 

2. M X =M 2 = P^ and p G Jz*; 

3. Mi = YYj=iNf\ where'ij G {l,...,m}, Nf Mf Nf ] follows from Q or (^1; 

4. Mi = (va)Nj, where NiMf N 2 ; 

5. Mi = def D in N u where Ni N 2 . 

Definition 6.10 (Bisimulation for soundness proof: processes) 

Given a downward-closed set of security levels Jzf C , the relation on processes is defined by: 
P\&^P 2 if there are M\,M% such that P = |M;| for i = 1,2 and M\ £%f ' M 2 . 
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We may now state our main result, namely that safety implies security. The proof consists in showing 
that safety implies Jzf-security, for any Jzf . The informal argument goes as follows. Let "low" mean "in 
J2?" and "high" mean "not in Jz? ". If P is not Jzf-secure, this means that there are two different observable 
low behaviours after a high input or in the two branches of a high conditional. This implies that there is 
some observable low action after the high input, or in at least one of the branches of the high conditional. 
But in this case the monitored semantics will yield error, since it does so as soon as it meets an action 
of level 1~^_}X, where pL is the monitoring level of the executing component (which will have been set to 
high after crossing the high input or the high condition). 

Theorem 6.11 (Safety implies security) IfP is safe, P is also secure. 



The converse of Theorem 6.1 1 does not hold, as shown by the process R of Example 4.10 A more 



classical example is s[l]?(2,;e T ).if x T then s[l] !(2,true- L ).0 else ^[l]!(2,true- L ).0. 
7 Conclusion 

There is a wide literature on the use of monitors (frequently in combination with types) for assuring 
security, but most of this work has focussed so far on sequential computations, see for instance O SJ 
[T4l . More specifically, [8] considers an automaton-based monitoring mechanism for information flow, 
combining static and dynamic analyses, for a sequential imperative while-language with outputs. The 
paper [4], which provided the initial inspiration for our work, deals with an ML-like language and uses a 
single monitoring level to control sequential executions. The work (U shows how to enforce information- 
release policies, which may be viewed as relaxations of noninterference, by a combination of monitoring 
and static analysis, in a sequential language with dynamic code evaluation. Dynamic security policies 
and means for expressing them via security labels have been studied for instance in lfT2l IT6l . 

In session calculi, concurrency is present not only among participants in a given session, but also 
among different sessions running in parallel and possibly involving some common partners. Hence, 
different monitoring levels are needed to control different parallel components, and these levels must 
be joined when the components convene to start a new session. As we use a general lattice of security 
levels (rather than a two level lattice as it is often done), it may happen that while all the participants 
monitors are "low", their join is "high", constraining all their exchanges in the session to be high too. 
Furthermore, we deal with structured memories (the Q-sets). In this sense, our setting is slightly more 
complex than some of the previously studied ones. Moreover, a peculiarity of session calculi is that data 
with different security levels are transmitted on the same channe ^](which is also the reason why security 
levels are assigned to data, and not to channels). Hence, although the intuition behind monitors is rather 
simple, its application to our calculus is not completely straightforward. 

Session types have been proposed for a variety of calculi and languages. We refer to 10 for a survey 
on the session type literature. However, the integration of security requirements into session calculi is 
still at an early stage. A type system assuring that services comply with a given data exchange security 
policy is presented in I ITOl . Enforcement of integrity properties in multiparty sessions, using session 
types, has been studied in j3j[T3l. These papers propose a compiler which, given a multiparty session 
description, implements cryptographic protocols that guarantee session execution integrity. 

We expect that a version of our monitored semantics, enriched with labelled transitions, could turn 
useful to the programmer, either to help her localise and repair program insecurities, or to deliberately 
program well-controlled security transgressions, according to some dynamically determined condition. 
To illustrate this point, let us look back at our medical service example of Figure[T]in Section|2] In some 



'Each session channel is used "polymorphically" to send objects of different types and levels, since it is the only means for 
a participant to communicate with the others in a given session. 
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special circumstances, we could wish to allow the user to send her message in clear, for instance in case 
of an urgency, when the user cannot afford to wait for data encryption and decryption. Here, if in the 
code of U we replaced the test on gooduse (form 1 ) by a test on no-urgency 1 A gooduse(form T ), then in 
case of urgency we would have a security violation, which however should not be considered incorrect, 
given that it is expected by the programmer. A labelled transition monitored semantics, whose labels 
would represent security errors, would then allow the programmer to check that her code's insecurities 
are exactly the expected ones. This labelled semantics could also be used to control error propagation, 
thus avoiding to block the execution of the whole process in case of non-critical or limited errors. In this 
case, labels could be recorded in the history of the process and the execution would be allowed to go on, 
postponing error analysis to natural breaking points (like the end of a session). 
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